1. The Field of the Invention
The present invention relates to novel systems and methods for controlling access, use, and authorization of encrypting applications hosted on computers. More particularly, the present invention relates to the use of separate modules, located within different access layers, for managing access to cryptography and for container policies in accordance with which access is granted.
2. The Background Art
Encryption is a technology dating from ancient times. In modern times, encryption of military communications has been common. However, since the famous xe2x80x9cENIGMAxe2x80x9d machine of World War II, cryptography has been used in numerous functions. One of those functions is special purpose software or applications that may be hosted on computers. Hiding underlying algorithms, limiting access, inhibiting reverse engineering, limiting unauthorized use, controlling licensure, and the like may be legitimate uses of cryptography.
Cryptographic Processes
Modem cryptography protects data transmitted over high-speed electronic lines or stored in computer systems. There are two principal objectives: secrecy, to prevent the unauthorized disclosure of data, and integrity (or authenticity), to prevent the unauthorized modification of data. The process of disguising plaintext data in such a way as to hide its substance is encryption, and the encrypted result is cyphertext. The process of turning cyphertext back into plaintext is decryption.
A cryptographic algorithm, also called a cipher, is the computational function used to perform encryption and/or decryption. Both encryption and decryption are controlled by a cryptographic key or keys. In modern cryptography, all of the security of cryptographic algorithms is based in the key or keys and does not primarily depend on keeping any details of the algorithms secret.
There are two general types of key-based cryptographic algorithms: symmetric and public-key. Symmetric algorithms (also called secret-key algorithms) are algorithms where the encryption key can be calculated from the decryption key and vice versa (and in fact these keys are usually the same). These require that a sender and receiver agree on these keys before they can protect their communications using encryption. The security of these algorithms rests in the key, and divulging the key allows anyone to encrypt and decrypt data or messages with it.
In public-key algorithms (also called asymmetric algorithms), the keys used for encryption and decryption different from each other in such a way that at least one key is computationally infeasible to determine from the other. To ensure secrecy of data or communications, only the decryption key need be kept private, and the encryption key can thus be made public without danger of encrypted data being decipherable by anyone other than the holder of the private decryption key. Conversely, to ensure integrity of data or communications, only the encryption key need be kept private, and a holder of a publicly-exposed decryption key can be assured that any ciphertext that decrypts into meaningful plaintext using this key could only have been encrypted by the holder of the corresponding private key, thus precluding any tampering or corruption of the ciphertext after its encryption.
Most public-key cryptographic algorithms can be used to provide only one of secrecy or integrity but not the other; some algorithms can provide either one but not both. Only the RSA (Rivest, Shamir, and Adleman) public-key algorithm (U.S. Pat. No. 4,405,829), whose security is based on the difficulty of factoring large numbers, has been able to be used to provide both secrecy and integrity.
A private key and a public key may be thought of as functionally reciprocal. Thus, whatever a possessor of one key of a key pair can do, a possessor of the other key of the key pair can undo. The result is that pairwise, secret, protected communication may be available without an exchange of keys. Thus, in general, a receiver, in possession of its own private key may decrypt messages targeted to the receiver and encrypted by the sender using the receiver""s public key. A receiver may authenticate the message, using its own copy of a sender""s public key, to decrypt data (e.g., a signature) encrypted with a sender""s private key corresponding to the sender""s public key.
An asymmetric algorithm assumes that public keys are well publicized in an integrity-secure manner. A sender (user of a public key associated with a receiver) can then know that the public key is valid, effective, and untampered with. One way to ensure integrity of data packets is to run data through a cryptographic algorithm. A cryptographic hash algorithm may encrypt and compress selected data. Such hash algorithms are commercially available. For example, the message digest 5 (MD 5), and the message digest 4 (MD 4) are commercially available software packages or applications for such functions.
A certificate may be thought of as a data structure containing information or data representing information, associated with assurance of integrity and/or privacy of encrypted data. A certificate binds an identity of a holder to a public key of that holder, and may be signed by a certifying authority. A signature is sometimes spoken of as binding an identity of a holder to a public key in a certificate. As a practical matter, a certificate may be very valuable in determining some level of confidence in keys associated with encryption. That is, just how xe2x80x9cgoodxe2x80x9d is an encryption in terms of privacy and integrity? That confidence level may be established by means of a certificate hierarchy. By certificate hierarchy is meant a certification process or series of processes for providing certificates from a trusted authority to another creator of keys.
A certificate, being a data structure, may contain, for example, data regarding the identity of the entity being certified as the holder of the key associated with the certificate, the key held (typically it is a public key), the identity (typically self-authenticating) of the certifying authority issuing the certificate to the holder, and a digital signature, protecting the integrity of the contents of the certificate. A digital signature may typically be based on the private key of the certifying authority issuing the certificate to the holder. Thus, any entity to whom the certificate is asserted may verify the signature corresponding to the private key of the certifying authority.
In general, a signature of a certifying authority is a digital signature. The digital signature associated with a certificate enables a holder of the certificate, and one to whom the certificate is asserted as authority of the holder, to use the signature of the certifying authority to verify that nothing in the certificate has been modified. This verification is accomplished using the certificate authority""s public key. This is a means to verify the integrity and authenticity of the certificate and of the public key in the certificate.
Cryptographic Policies
Government authorities throughout the world have interests in controlling the use of cryptographic algorithms and keys. Many nations have specific policies directed to creation, use, import, and export of cryptographic devices and software. Numerous policies may exist within a single government. Moreover, these policies are undergoing constant change periodically.
Cryptographic policies may limit markets. For example, a cryptographic algorithm may not be included in software shipped to a country having laws restricting its importation. On the other hand, such a cryptographic device may be desired, highly marketable, and demanded by the market in another country. Thus, generalized software development, standardization of software, and the like may become difficult for software vendors. Moreover, users have difficulties attendant with supporting limited installed bases of specialized software. That is, a sufficient installed base is required to assure adequate software.
In short, cryptographic use policies sometimes constrain the set of cryptographic algorithms that may be used in a software system. In addition to restrictions on allowable algorithms, cryptographic use policies may also place constraints on the use and strength of keys associated with those algorithms. Software shipped or used in any country must be in compliance with the policies extant.
Another common aspect of certain cryptographic use policies is a requirement that a copy of cryptographic keys be stored or xe2x80x9cescrowedxe2x80x9d with an appropriate authority. However, the mechanisms necessary to satisfy different policies can vary greatly.
Cryptography, especially public key cryptography, provides certain benefits to software designers. U.S. Pat. No. 4,200,700, U.S. Pat. No. 4,218,582, and U.S. Pat. No. 4,405,829 are directed to such technology and are incorporated herein by reference. These benefits are available in situations where data may be shared. Many modern software packages (applications, operating systems, executables) are used in businesses or in other networks where multiple xe2x80x9cclientsxe2x80x9d may share a network, data, applications, and the like. Most modem software packages employ cryptography in some form.
One application for cryptography in network management or network operating systems includes authentication. Also, integrity of data packets transferred, encryption of files, encoding associated with licenses for software or servers, and license distribution or serving are some of the applications for cryptography.
Users may be identified and their rights to access may be authenticated by means of passwords on a network. Cryptography is typically used to transfer some authentication, integrity, verification, or the like in a secure manner across a network that may be open to channel tapping. Public key cryptography is typically used in such a circumstance. Another application of cryptography for authentication involves a single sign-on. For example, a user may need to enter a single password at the beginning of a session. This may remain true regardless of the number of servers that may eventually be called into service by the individual user (client) during this single session. Historically, scripts have been used to provide a single sign-on, but public key mechanisms are now being provided for this function.
Users have previously demonstrated that networks may be subject to attack by spoofing of network control packets. This procedure may be demonstrated in playback and in man-in-the-middle scenarios. By such spoofing, users may obtain unauthorized privileges on a network server. Adding packet signatures, keyed on a per-session basis may provide improved packet integrity.
File encryption is becoming more available. Such encryption has particular use in the special circumstance of audit files. For example, a need exists to protect an audit trail from inspection or modification, or both, by a system administrator, even though the audit trail remains under the system administrator""s physical control.
Certain licensing schemes may use various encryption modes to protect software against piracy by end users and others throughout a distribution chain. Data structures, cryptography methodologies, checks, and other protection mechanisms may be proprietary to a software developer. Nevertheless, license server mechanisms are being developed to support control of the use of application software in conformity with licenses. Licenses may be provided by an application software provider. The license server may use public key cryptography to create and verify signed data structures. Secret key cryptography may be used to support authentication and file encryption.
Certain applications may provide file confidentiality using proprietary, exportable, secret key algorithms. Users in large numbers make use of such algorithms. Nevertheless, considerable interest in breaking such proprietary algorithms has been successful with certain software. Proprietary encryption methodologies have been consistently broken, given enough time and attention by interested hackers.
Certain applications use public key cryptography for digital signatures. Market leaders in software have provided relatively weak secret key algorithms adopted by others. Thus, files written in different applications from different vendors, even encrypted files, may be opened by an application from any of the vendors using the market leader""s secret key algorithm. Within a single product line, a vendor of software applications may use multiple algorithms. Several, if not a plethora of, algorithms exist, including both secret key algorithms and public key algorithms. Stream and block ciphers, as well as hash functions are available and well documented in the computer programming art. Also, certain algorithms are the subject of patent applications which may cloud their broadly based use.
What is needed is a standardized cryptography methodology for distribution across entire product lines. Moreover, encryption technologies are needed for permitting a licensee of a principal software manufacturer to become a third party vendor or value-added distributor capable of producing its own proprietary software, software additions, or pre-planned software modules. Currently, software-with-a-hole may provide an operating system with a cryptographic module that fits in the xe2x80x9cholexe2x80x9d in an operating system. However, software manufacturers using this technology typically require that a third-party vendor send its product to the principal software manufacturer for integration. The manufacturer may then provide all interfacing and wrapping of the third-party""s filler (such as an encryption engine) to fit within the xe2x80x9cholexe2x80x9d in the software of the manufacturer.
Also, export restrictions exist for encryption technology. Limiting the strength of exported cryptography is established by statute. To be exportable, such products must meet certain criteria (primarily limitations on key size) that effectively prevent the exportation of strong cryptographic mechanisms usable for data confidentiality. Moreover creating xe2x80x9ccryptography with a holexe2x80x9d is undesirable for several reasons, including export and import restrictions. Cryptography with a hole is the presence of components specifically designed or modified to allow introduction of arbitrary cryptographic mechanisms by end users. A great escalation of the difficulty of such introduction, without creating numerous, individually customized software packages, is a major need today, although not necessarily well-recognized.
Certain foreign countries have more stringent regulation of the importation of encryption technology by non-government entities. A government may require that any imported encryption technology be subject to certain governmental policies as well as key escrow by some governmental agency. Key escrow systems may be easily provided in software, but integrity and assurance remain difficult. Using only software, reliable key escrow may be impossible, in the absence of very high assurance. For example, Class B3 or A1 may be required of a xe2x80x9ctrusted computing basexe2x80x9d in order to protect keys against disclosure or modification. Likewise, protection of algorithms against disclosure or modification, and escrow against bypass, are also often required. Under any circumstances, software offers few protections when compared with hardware solutions.
Customers, whether third-party vendors, distributors, or end users, need information security. International commercial markets need products that may be marketed internationally without a host of special revisions that must be tracked, updated, and maintained with forward and backward compatibility as to upgrades and the like. Meanwhile, such solutions as key escrow do not receive ready customer acceptance in U.S. markets, particularly where a government is an escrow agent.
Flexibility of encryption technologies is also important, particularly to software development. For instance, it is important that standards or properties be created for managing access to encryption technologies. At the same time, it is likely that the properties will change over time, and the properties should be easily modified. The properties should also be securely contained with specific applications implementing the encryption technologies.
Therefore, what is needed is a cryptography apparatus and method that may be mass produced in a variety of products across an entire product line. A technology, or product that can be sold in identical form both domestically and abroad is highly desirable. An encryption method and apparatus are needed that may provide improved methods for security and integrity of data provided by cryptographic algorithms and keys themselves, without requiring xe2x80x9ctrustxe2x80x9d between sender and receiver.
Also needed is a key escrow mechanism for corporate environments. For example, file encryption by an employee will usually be required to be subject to an escrow key in the possession of the employer. Also, in conjunction with signature authorities, delegation of such authority may be useful in a corporate environment. Nevertheless, each corporate user may be viewed as a secondary (vendor) level desiring to have its own encryption and escrow control of all copies of all keys.
What is needed is a method for producing cryptographic applications that may be customized individually, from individual modules. That is, what is needed is modules that may be used to limit the capabilities of cryptographic applications without proliferating individual customized software products that may become very difficult to maintain, upgrade, support, and the like. What is needed is an apparatus and method that can separate a cryptography application or a cryptography filler for an operating system xe2x80x9cslotxe2x80x9d into modules. Modules need to be configured to minimize the extent of interfaces and the amount of code that must be interfaced. Modules should minimize the number of exclusions from a system that must be patched or replaced in order to enable the software system to satisfy relevant cryptography usage policies.
Such a system is also needed in which a cryptography filler can be provided with separate access manager and access properties modules. Such property modules should be securely loaded within deeper, less accessible layers than the manager modules and should be subordinate to one manager module, responding when called by one manager modules.
What is needed also are an apparatus and method effective to enable a manufacturer of a cryptographic engine to produce a single implementation of a modular package embodying particular cryptographic algorithms. The manufacturer should remain able to include that implementation in all versions of a software product. This should be true regardless of different key usage policies mandated by various regulatory authorities. It should be true regardless of a requirement for disabling of certain of the included algorithms.
Also needed is an alternative to prior art systems that require both a xe2x80x9cpolicyxe2x80x9d and an algorithm implementation to be supplied (even lastly shipped) from the manufacturer of a cryptography engine as the wrapping and certifying entity. Instead, what is needed is an apparatus having an architecture and implementation by which a manufacturer of a cryptographic engine need not be the same entity as a supplier/generator of a policy (e.g. government) to which the cryptographic engine""s algorithms are constrained to conform.
Beneficial, and therefore desirable or needed, is an apparatus and method having distinct executable modules and policy data structures sufficiently separable to reduce the cost of customizing an entire software system. Thus, a system is needed that is adaptable to inexpensive customization without implementing an embedded policy.
Also needed is an apparatus and method for separating a policy from an algorithm to enable flexibility in the management and delivery of cryptographic capabilities in conformance with the local regulations. For example, some method is needed by which a manufacturer can produce a cryptographic engine, but exclude a policy certificate permitting use of the algorithms implemented by that engine. That is, a method is needed by which a manufacturer or one or more other policy certificate authorities may separately offer key and policy authorization, certification, and verification conforming to local regulations.
In view of the foregoing, it is a primary object of the present invention to provide an apparatus and method comprising distinct, controlled modular cryptography modules and policy data structures.
It is another object of the invention to provide such an apparatus and method whereby separate manager and subordinate policy modules are dynamically loaded of modules into a base executable in a manner to prevent substitution, modification, extension, or misuse of algorithms implementable by the modules.
It is another object of the invention to provide such separate manager and subordinate policy modules whereby different policies may be implemented by modifying the policy modules without modifying the manager modules and whereby the modified policy modules may be independently indicated as coming from an intended vendor.
Consistent with the foregoing objects, and in accordance with the invention as embodied and broadly described herein, an apparatus and method are disclosed in certain embodiments of the present invention as including a controlled modular cryptography system.
A principle feature provided by an apparatus and method in accordance with the invention includes limitation of software integration. For example, a software integration limiter may provide a cryptographic operating system with a xe2x80x9cslot.xe2x80x9d That is, an operating system may be thought of as a block of executable instructions storable in a memory device, and loadable on a processor.
A software integration limiter in accordance with the invention may provide an architecture and coding to limit the integration of coding required to fill a xe2x80x9cslotxe2x80x9d left within an operating system. Thus, the operating system or other software cannot operate at all, or may be configured to not operate with cryptographic capability, absent an authorized, added software xe2x80x9cfillerxe2x80x9d filling the xe2x80x9cslotxe2x80x9d.
Another feature available in an apparatus and method in accordance with the invention may be a vendor-constrained, remotely sealed, software integration limiter. For example, prior art systems may require that a manufacturer receive, license for import, and wrap the code of value-added resellers and vendors, incorporating the codes into a cryptographically enabled software product.
By contrast, an apparatus and method in accordance with the invention may provide for a universal xe2x80x9cbase executablexe2x80x9d comprising a software system for operating on a computer. A software development kit may be provided with certain authorizations to an agent, vendor, distributor, or partner. The authorizations may be provided as certificates permitting the agent to create software modules and wrap them without their contents being known, even to the original manufacturer of the xe2x80x9cbase executablexe2x80x9d or the software development kit. Such a system may then include a constrained policy obtained by the agent, vendor, etc., in cooperation with a government, to meet the import laws of the country of sale of the entire package, the software xe2x80x9cbase executable,xe2x80x9d modules from vendors, and an authorizing policy. Such a system may allow an agent (development partner, third party value-added seller, module vendor, distributor) to provide sealed encryption algorithms. The algorithms may remain known only to the agent, (partner, distributor, etc.) although accessed for linking using keys authorized by the manufacturer of the base executable.
The software development kit may provide for an authorization mechanism, such as a certificate of authority immediately identified with the software development kit and the agent. Any xe2x80x9cbase executablexe2x80x9d may then verify any module from any vendor to determine that the vendor has produced a module in accordance with policy constraints imposed on the software development kit and verified by the xe2x80x9cbase executablexe2x80x9d produced by the manufacturer.
Thus, a universal xe2x80x9cbase executablexe2x80x9d may be exportable by a manufacturer and importable by a distributor or reseller. A distributor may be responsible to obtain the proper licensure for cryptographic equipment and functionality. The xe2x80x9cbase executablexe2x80x9d can verify that all modules by a distributor come from a software development kit operating within its bounds of policy authorization and other permitting functionality.
In short, the xe2x80x9cbase executablexe2x80x9d knows how to recognize a valid signature provided from a module created on a proper software development kit. A software development kit may produce or generate proper digital signatures. The agent""s, distributor""s, or partner""s module product may then carry the proper signature. Therefore, the xe2x80x9cbase executablexe2x80x9d may recognize and run only those modules having valid signatures corresponding to software development kit xe2x80x9ctoolboxesxe2x80x9d of known, authorized agents or distributors, and in accordance with authorized policies.
Another feature of an apparatus and method in accordance with the invention may be a null engine. A null engine may be provided by a manufacturer with any xe2x80x9cbase executablexe2x80x9d (principal software product, operating system), having no enabled cryptographic capability. Nevertheless, the null engine may support all interfaces required by a xe2x80x9cslotxe2x80x9d in the base executable, and all functionalities except cryptographic capabilities required by a xe2x80x9cfiller.xe2x80x9d Thus, for example, an operable software system may be delivered having no cryptographic capability, simply by providing a filler including a null engine to fill the xe2x80x9cslotxe2x80x9d within the software product (operating system, base executable) provided by the manufacturer.
Another feature of the apparatus and method in accordance with the invention may be flexible key escrow capability. This feature may be thought of as a modular key escrow method. Escrow capability may escalate from a self escrow. For example, an individual company, individual user, or the like, may hold and control all keys. At an opposite extreme, an escrow of a key may reside with some other independently authorized escrow agent. A key escrow may reside with a governmental agency itself as required in some countries.
Another feature of an apparatus and method in accordance with the invention may include cryptographic wrapping of keys. That is, wrapping may be thought of as tamper proofing (authentication) and encrypting (secrecy protection) a key. Prior art system""s keys may be simply bit strings of sufficient length and complexity to reduce the probability of their being deciphered.
Here, a holder""s identification and a certification authority""s identification may be applied to a key itself. The digital signature of the certifying authority may enable verification of such certification. The keys may be centrally managed, such as by a management module in the xe2x80x9cbase executablexe2x80x9d from a manufacturer. Such a module can therefore restrict creation, distribution, and use of keys, especially within a network or internetwork.
Another feature of an apparatus and method in accordance with the invention may include quality-graded certificates. The certificates may be generated by distributors (value-added resellers, module vendors, agents, partners). However, the certificates may provide a xe2x80x9cpedigreexe2x80x9d indicating an integrity level of the cryptography provided by a certificated software product. Thus, a purchaser of software who will become a user or owner (holder) may know the cryptographic strength (algorithm, key length) or quality (integrity; value limit of assurance) of the systems used or created, with a verification that cannot be forged.
Another feature of an apparatus and method in accordance with the invention may be provision of cryptographic engines that are not independently usable. For example, cryptographic engines may be comprised of, or included with, wrapped, non-linkable modules that can only be used in a filler to fill a xe2x80x9cslotxe2x80x9d in a base executable (principal software application) from a specified manufacturer. Thus, unlike the prior art where a cryptographic engine obtained by a vendor or third party may be used with any software, cryptographic engines made in accordance with the invention may not be enabled absent verification of their integrity, applicability, policy, or the like by a base executable (principal software product). For example, a base executable, such as an operating system or other manufacturer-supplied module may verify any and all modules attempting to link with the base executable and vice versa.
Another feature of an apparatus and method in accordance with the invention may be constraining the linking of modules to a specific class of module, or within a specific class of module, through the use of cryptography. Thus, for example, a hierarchy of linking may be created within individual software modules, so that all modules may link only to peers (associated modules in one filler) and may not necessarily be able to link directly with selected modules of the total group of peer modules with the same filler. For example, an application or library module may not bypass an access limiting manager module to interface with a cryptographic engine module.
Another feature of an apparatus and method in accordance with the invention is that modules such as the access limiting manager modules may rely upon other modules such as the policies of modules, which may be located at a lower hierarchal linking layer than the manager module. The manager module and the policies modules may be independently dynamically linked. Accordingly, the policies module may be modified, and the modifications can then be authenticated as coming from a project vendor by the base executable.
Thus, the above objects may be met by one or more embodiments of an apparatus and method in accordance with the invention. Likewise, one or more embodiments of an apparatus and method in accordance with the invention may provide the desirable features as described.